[Bug] (blocking) The supersedes relation direction is inverted for MERGE decisions.

In the MERGE flow, the candidate memory is not created (decision=NONE). Its content is merged into the existing memory, which survives with updated content. However, this code creates:

pending://... --supersedes--> existing_memory_uri

When HierarchicalRetriever._apply_memory_relations() later calls is_superseded(existing_uri), it returns True because there's a supersedes relation targeting the existing URI. This causes the surviving, updated memory to be filtered out of retrieval results.

The PR description's example assumes MERGE produces two distinct URIs (theme_001 and theme_002), but the actual code flow is:

• Candidate has no URI → falls back to pending:// scheme
• Existing memory keeps its URI and gets updated content
• The relation incorrectly marks the kept memory as superseded

For MERGE, either:

1. Don't create a supersedes relation (MERGE is an update, not a replacement), or
2. Use a different relation type (e.g., derived_from) to record the merge audit trail without affecting retrieval filtering

[Design] (blocking) The entire feature is dead code — nothing is wired up.

1. This router is never registered in app.py (app.include_router not called, not added to routers/__init__.py)
2. MemoryRelationStore is never instantiated during service startup
3. MemoryDeduplicator instantiation in compressor.py:68 doesn't pass relation_store
4. HierarchicalRetriever instantiation in viking_fs.py:647,792 doesn't pass memory_relation_store

Please either:

• Add the wiring code (service init → store creation → inject into dedup/retriever/router), or
• Explicitly document this as Phase 1 (data model only) with a follow-up issue for the wiring

[Suggestion] (non-blocking) RelationType(type) raises ValueError for invalid enum values, resulting in a 500 instead of 400.

Also, the direction parameter accepts any string without validation — passing direction="invalid" silently returns empty results.

Consider:

try:
    relation_type = RelationType(type) if type else None
except ValueError:
    return Response(status="error", error=ErrorInfo(code="INVALID_ARGUMENT", message=f"Invalid relation type: {type}"))

if direction not in ("outgoing", "incoming", "both"):
    return Response(status="error", error=ErrorInfo(code="INVALID_ARGUMENT", message=f"Invalid direction: {direction}"))

Or use FastAPI's enum parameter validation by defining direction as a Literal["outgoing", "incoming", "both"].

[Suggestion] (non-blocking) The schema defines account_id but MemoryRelation dataclass has no corresponding field. When you implement VikingDB persistence, this mismatch will need to be resolved — either add account_id to the dataclass or remove it from the schema.

[Suggestion] (non-blocking) _apply_memory_relations has no test coverage. Given the supersedes direction bug identified in _record_dedup_relations, an integration test that exercises the full dedup → retrieval pipeline would catch this class of issues.

Consider adding a test that:

1. Creates a MERGE dedup result and records relations
2. Runs _apply_memory_relations on a result set containing the merged memory
3. Asserts the merged memory is not filtered out